Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/ident/ident-minutes-92jul.txt

Text File | 1993-02-17 | 5.2 KB | 156 lines

Editor's Note:  Minutes received 7/20


CURRENT_MEETING_REPORT_


Reported by Mike St.  Johns/DOD and Dave Borman/Cray Research

Minutes of the TCP Client Identity Protocol Working Group (IDENT)

Discussion Items


   o Security Section
   o Format of User IDs
   o Character Set
   o Error Response
   o MIB


Security Section

The security section has been argued/discussed to death on the mailing
list - the current text represents what the Chair considers a reasonable
compromise.  The Chair did not want to reopen the section again.

After a little discussion about generalities (e.g., Is the section too
big?; Is the section too small?), Marshall Rose stated that ``Finger has
a large security section, it's a fact of life that with documents like
this a longer security section is needed.''  Steve Crocker said that ``I
read this from scratch - thought about dropping last two paragraphs, but
then decided they were important.''  The Chair polled the room on three
questions:


  1. Section too strict:  0
  2. Section not strict enough:  2
  3. OK as is:  13
  4. No opinion:  5


(Note that there was some overlap between ``not strict enough'' and
``OK'' - the ``too strict'' people were willing to accept as stands).
The Chair said there was not enough heartburn to warrant reopening
section and was not shouted down, so section is CLOSED and will stand as
it is currently.

At the request of Marshall Rose, the Group discussed the MIB document
out of turn.

There was a brief discussion on how MIB document relates to Ident
protocol.  We noted that the only critical overlap was the security
section.  As we had closed the security section, without objection, the
Chair declined to pull the MIB document back from standards submission.
Please note that objectors may send their comments to the IESG during
the normal two week comment period once the document is announced.

                                   1





Format of Userids

There was a lot of very good discussion here on character length and
format:  Why limit UNIX to 8 characters?  Should we get rid of OPSYS
field?  The character set information is useful and the rest should be
arbitrary?  MIME is specifying US-ASCII instead of NVT-ASCII.

The final result of the discussion was to redesignate OCTET as a
character set indicator; to remove the syntax implications from the
OPSYS ID [a ``real'' operating system identifier implies a ``real'' user
identifier, but does not indicate any specific syntax of the user
identifier]; and to make US-ASCII the default character set vs
NVT-ASCII.

Random Interjections

There was a brief discussion on the feasibility of using UDP for
transport but the general consensus was that it was not a good idea.  By
using UDP as the transport, it would be very easy to spoof the response
- even more so than is possible in TCP.

The point was make that there needs to be something in overview about
the client shutting down the connection if it gets no response.  The
Chair accepted this and took for action.

Stever Crocker asked if the server is allowed to respond on a selected
basis, and is the server allowed to respond with something not directly
interpretable?  The Chair deferred the first part for later discussion,
but pointed Steve at the ``OCTET'' operating system identifier and the
``OTHER'' character set identifier for the second part.

Steve also indicated a problem with the ``Query/Response'' section; he
got lost reading this.  He suggested ``Port on Client Machine/Port on
Server Machine'' vs.  ``local/remote''.  The Chair accepted this and
will edit it.

Character Sets

This section remains open for one go-around on the items suggested
above.

Error Responses

There were two proposals:


  1. Allowing the server to return ``NONE'' for machines like MS/DOS or
     others which don't have the concept of a userid.  This was rejected
     on the basis we'd have to reserve ``NONE'' and no one could use it
     as a userid.  Systems like this should use the ``NO-USER'' error
     code instead.


                                   2





  2. Allowing the server to return ``HIDDEN-USER'' as an error code.
     The code would mean the system had valid user information for this
     query, but refused to return it at the request of the user.  The
     consensus was to accept it.


Attendees

Steve Alexander          [e-mail]
Mark Baushke             [e-mail]
David Borman             [e-mail]
Luc Boulianne            [e-mail]
Stephen Crocker          [e-mail]
Peter DiCamillo          [e-mail]
Chas DiFatta             [e-mail]
Tom Farinelli            [e-mail]
Barbara Fraser           [e-mail]
Ned Freed                [e-mail]
Cliff Frost              [e-mail]
Pria Graves              [e-mail]
Bradley Rhoades          [e-mail]
April Richstein          [e-mail]
Marshall Rose            [e-mail]
Robert Shirey            [e-mail]
Jeremy Siegel            [e-mail]
Michael St.  Johns       [e-mail]
Theodore Ts'o            [e-mail]
John Wagner              [e-mail]
Walter Wimer             [e-mail]



                                   3